Sub-network connection protection (SNCP) is a path protection mechanism defined in ITU-T G.841, “Types and characteristics of SDH network protection architectures,” which is similar to unidirectional path switched rings (UPSR) in the SONET standard. SNCP utilizes a permanent source bridge on an ingress port, and a selector function at an egress port. SNCPs are unidirectional and switching is performed similarly to a 1+1 and UPSR protection mechanisms. SNCP services are 1+1 protected services that provide protection in a network in the presence of one failure, with minimal traffic-impacting switching ability.
Referring to FIG. 1, in a network 100 with a SNCP service, two paths 102, 104 (also referred to as legs) are provisioned through the network 100. The network 100 can include multiple switches 106 including an ingress switch 106a and an egress switch 106b. The switches 106 can include optical switches operating SONET, SDH, Optical Transport Network (OTN), or the like along with a control plane including a signal and routing protocol, such as Optical Signal and Routing Protocol (OSRP) or the like. Both the paths 102, 104 carry the same traffic stream, and a select function is used to select one of the two streams. In case of a failure of an active stream, a simple switch at the egress switch 106b, a device attached to the egress switch 106b, or the like is able to protect the service. Advantageously, the SNCP service experiences smaller down time as compared to other protection schemes such as a full mesh restoration on an ordinary sub-network connection (SNC) service.
In general, the ability to provide SNCP protection does not rely on the network's 100 structure, i.e. it does not depend on the existence of rings for line switched ring (LSR) protection or with duplicate equipment for APS/MSP protection. The ability to provide SNCP protection does depend on the ability to establish the two paths 102, 104 through the network 100 such that they are fully disjoint from the point of view of failure points—so that no single failure can affect both paths 102, 104 at the same time. For example, in a mesh network of optical switches, availability of single-failure disjoint paths generally translates into OSRP Bundle ID diversity.
While SNCP services in general are resilient to single failures, they may not be resilient to dual failures that affect the two paths 102, 104 of the service. The introduction of Mesh Restorable SNCP (MR-SNCP) services aims at providing services that are potentially resilient to dual failures, as long as failure-disjoint paths can be established through the network post-failure.
Referring to FIG. 2, the network 100 includes a MR-SNCP on the two paths 102, 104. In a MR-SNCP, the occurrence of a failure 206 is protected in the same way as an ordinary SNCP service, i.e. through a selection switch at the egress switch 106b. Unlikely previous SNCP services, the path 102 that is affected by the failure 206 attempts protection or mesh restoration in the same way as an ordinary SNC, such as possible protect switching and local span mesh restoration (LSMR). For example, the path 102 is rerouted to a path 202 upon the occurrence of the failure 206, providing redundancy for the MR-SNCP service. Advantageously, upon occurrence of a second failure 208, the MR-SNCP service can still be protected through a selection switch. Moreover, additional failures can keep being protected through a selection switch as long as the path 104 that was affected by the most recent failure 208 can migrate to a path 204 that is failure-disjoint from the currently active path. Notice that resiliency to dual failures is not assured solely by the introduction of the MR-SNCP feature, but it requires some degree of diversity in the network layout itself.
When network failures impact both working and protection paths 102, 104, both paths 102, 104 need to be restored onto additional bandwidth. Disadvantageously, this can cause bandwidth contention among multiple circuits, lack of absolute route diversity between paths, lower priority circuits hogging bandwidth and blocking mesh restoration of higher priority circuits, and the like. Existing MR-SNCP services suffer with a problem that moving a peer path to a new path could overlap with the existing home path or current path of the peer SNC. The reason for such a behavior is due to treating the other path's current and home path as preferred exclusive path and not as mutual exclusive path. This leads to both the MR-SNCP legs double booking some of the same links or bundles under such conditions. In such scenarios, a single failure can lead both the paths to go down and there is no protection switch guaranteed at that time.
Currently there is no support for the above shortcomings in any customer-deployed network